This has been discussed before. I have mixed feelings. A great deal of the code is predicated on the assumption of an unreliable transport medium; mqtt_as therefore seems like overkill for a wired connection. This doc summarises my views.

Further comment is welcome. @bobveringa ?

It would heavily depend on the implementation. The implementation as described above I think would add a lot of complexity and benifit very few people.

This has been proposed before (and is currently still open) in #57.

On the one hand, this does allow for more flexibility in using the driver. On the other it adds more complexity and code. One advantage I could think is that integration testing and other kinds of testing can be easier to implement, and it might be easier to get the library to work on more ports. But I have done no validation or testing to validate if it is actually easier.

When I have time to work on investigating testing I can take this issue into account, but this might take a while.

Thanks for the feedback. I did see #57 (after I'd started making the changes here) and still thought this might be worth sharing as it's a much smaller change, mostly contained to a couple of sections of the code.

@peterhinch while I do agree with your thoughts in FUTURE_DEVELOPMENT when I went looking for an asyncio mqtt library to use to test and demo my USB NET pr this was the only one I found for micropython. I figured a fairly minimal amount of changes to it would make it work on pretty much any micropython network interface, without adding any more dependencies to get it working.

I did briefly try https://github.com/zcattacz/mqtt_as that was linked in one of the issues here but wasn't able to make it connect to my broker, I'm not sure why.

Longer term, there's a couple of pure-python mqtt libraries that might port from cpython pretty easily I might try next instead:

• mqttools - mqtt 5.0 client & broker, only qos 0.
• gmqtt - mqtt 5.0 client, minimal dependencies.
• amqtt - client & broker, larger library, few more dependencies that would need to be worked around

I'd actually really like to try running the broker on micropython as well for use cases over USB where I'd like a desktop client app to be able to talk directly to the micropython board, rather than needing an additional server installed and configured, so mqttools could be a good fit.

I think a stripped-down version for wired interfaces along the lines of https://github.com/zcattacz/mqtt_as may be the best way forward. I'm wary of adding complexity to the core mqtt_as which aims to support MQTT3.1.1 on ESP8266.

A version supporting a variety of network interfaces also presents a workload in testing, documentation and support.